Once the release is classified and the policy, which needs to be adopted, is assigned, the Release Manager must plan for the release in coordination with the Change Coordinator /Change Manager and the Build and Test Teams. A Release And Deployment Plan must be prepared which includes:

• Scope and content of the release. This should contain the changes to be included in a particular release i.e. the release units / release components.
• Nature of the release. This could be full, delta, or package releases.
  • Full release indicates all components of the release unit must be put through the process.
  • Delta release indicates only those elements, which have changed since the last release are to be put through the process.
  • Package release indicates a logical grouping of releases (full or delta), which can be rolled-out simultaneously.
• Risk profile of the release. This should include service impact and the possible risks of both implementing and not implementing. The mitigation and contingency plans for the risks must also be determined. Dependencies and constraints for the release must also be identified.
• Release strategy (for build and test) and deployment strategy.
• Development Plan for building release components.
• The schedule for release and deployment should be in line with the overall change plan and schedule. The schedule should be prepared based on deployment strategy taking account of geographical locations, business units and customers. Planning should also include which components need to be deployed, users, user locations, dependencies, need of deployment, Timelines, entry exit criteria, deployment approach logistics etc.
• Stakeholders affected by the release. User locations for deployment.
• Team responsible for the entire release and deployment. This would include resources for the release build, test and deployment, and for early life support.
• Release documentation
• Release testing strategy. This would include test acceptance criteria, approach and schedules for different types of testing (e.g. regression testing, performance testing, load testing, end to end testing of system components, user Acceptance Testing (UAT), operation Acceptance Testing (OAT), etc.).
• Roll back options and back out procedures
• Environments for the release (development, test, pre-production, production)
• Plan for release pilots
• Release back out plans
• Release handover and training plan (if any)
• Metrics for monitoring and determining the success of the release deployment.

The Release Manager must ensure that the release planning is integrated with releases of other applications. Conflicts if any should be avoided. A Release Calendar, which must be in sync with enterprise calendar, should be published. The Release Manager should also evaluate financial and commercial aspects before planning for a deployment. Ideally a release should not be planned or scheduled into an already booked window to avoid clashes. Activities that were scheduled into a time window prior to a release take a priority over the release, unless it is decided otherwise by the responsible stakeholders. The emergency releases are carried out in accordance with the procedures meant for emergency changes.